<p>This rule raises an issue when Node.js built-in modules are imported without using the <code>node:</code> protocol prefix.</p>
<h2>Why is this an issue?</h2>
<p>When importing Node.js built-in modules, using the <code>node:</code> protocol makes it explicitly clear that you’re importing a core Node.js
module rather than a third-party package from npm.</p>
<p>Without the <code>node:</code> prefix, it can be ambiguous whether <code>import fs from 'fs'</code> refers to the built-in file system module or a
potential npm package named 'fs'. This ambiguity can lead to confusion, especially for developers who are new to a codebase or when reviewing
code.</p>
<p>The <code>node:</code> protocol was introduced in Node.js 12.20.0 and became the recommended approach for importing built-in modules. It provides
several benefits:</p>
<ul>
  <li> <strong>Clarity</strong>: Makes it immediately obvious that the import refers to a Node.js built-in module </li>
  <li> <strong>Security</strong>: Prevents potential confusion attacks where malicious packages could have names similar to built-in modules </li>
  <li> <strong>Future-proofing</strong>: Aligns with Node.js best practices and ESM standards </li>
  <li> <strong>Consistency</strong>: Creates a uniform way to reference all built-in modules </li>
</ul>
<p>This practice is particularly important in larger codebases where the distinction between built-in modules and external dependencies needs to be
clear at a glance.</p>
<h3>What is the potential impact?</h3>
<p>Using imports without the <code>node:</code> protocol can lead to confusion about whether a module is built-in or external. In rare cases, this
could create security vulnerabilities if malicious packages with names similar to built-in modules are installed. The lack of explicit protocol also
makes code less self-documenting and harder to understand for new team members.</p>
<h3>How to fix?</h3>
<p>Add the <code>node:</code> prefix to ES6 import statements when importing Node.js built-in modules.</p>
<h4>Non-compliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
import fs from 'fs';
import path from 'path';
import { createServer } from 'http'; // Noncompliant
</pre>
<h4>Compliant code example</h4>
<pre data-diff-id="1" data-diff-type="compliant">
import fs from 'node:fs';
import path from 'node:path';
import { createServer } from 'node:http';
</pre>
<h3>Documentation</h3>
<ul>
  <li> <a href="https://github.com/sindresorhus/eslint-plugin-unicorn#readme">eslint-plugin-unicorn</a> - Rule <a
  href="https://github.com/sindresorhus/eslint-plugin-unicorn/blob/HEAD/docs/rules/prefer-node-protocol.md">prefer-node-protocol</a> </li>
  <li> Node.js ESM Documentation - Node Imports - <a href="https://nodejs.org/api/esm.html#node-imports">Official Node.js documentation explaining the
  node: protocol for importing built-in modules</a> </li>
  <li> Node.js Modules Documentation - <a href="https://nodejs.org/api/modules.html">Complete reference for Node.js built-in modules and module
  system</a> </li>
</ul>
<h3>Standards</h3>
<ul>
  <li> ECMAScript Modules (ESM) - <a href="https://tc39.es/ecma262/#sec-modules">ECMAScript specification for module syntax and semantics</a> </li>
</ul>
